home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000051_owner-urn-ietf _Thu Oct 17 07:57:37 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  4KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA01194 for urn-ietf-out; Thu, 17 Oct 1996 07:57:37 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA01189 for <urn-ietf@services.bunyip.com>; Thu, 17 Oct 1996 07:57:34 -0400
  3. Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA23440  (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 07:55:11 -0400
  5. Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1)
  6.     id E0vDqy3-0005QF-00; Thu, 17 Oct 1996 12:50:27 +0100
  7. Date: Thu, 17 Oct 1996 12:50:26 +0100 (BST)
  8. From: Jon Knight <jon@net.lut.ac.uk>
  9. X-Sender: jon@weeble.lut.ac.uk
  10. To: Larry Masinter <masinter@parc.xerox.com>
  11. Cc: liberte@ncsa.uiuc.edu, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  12. Subject: Re: [URN] a possible security architecture for URNs
  13. In-Reply-To: <96Oct17.022129pdt."2771"@golden.parc.xerox.com>
  14. Message-Id: <Pine.SUN.3.95.961017123028.8636a-100000@weeble.lut.ac.uk>
  15. Mime-Version: 1.0
  16. Content-Type: TEXT/PLAIN; charset=US-ASCII
  17. Sender: owner-urn-ietf@services.bunyip.com
  18. Precedence: bulk
  19. Reply-To: Jon Knight <jon@net.lut.ac.uk>
  20. Errors-To: owner-urn-ietf@bunyip.com
  21.  
  22. On Thu, 17 Oct 1996, Larry Masinter wrote:
  23. > I want to be able to transition from
  24. > 
  25. > Herman Melville's Moby Dick
  26. > to
  27. > LOC's Herman Melville's Moby Dick
  28. > or
  29. > OCLC's Herman Melville's Moby Dick
  30. > 
  31. > The naming scheme in SDSI not only allows relative names, but some way
  32. > of merging the trees (or not, as you choose).
  33.  
  34. Er, but surely these are just different instances (locations) of the same
  35. resource?  So the URN will return a number of pointers to possible
  36. resources?  Or am I misunderstanding what you mean?
  37.  
  38. > As long as you have a completely global name space, you don't have a
  39. > way to talk about migration. By adding relative paths and later
  40. > identity, you can deal with migration by asserting that there are some
  41. > authorities YOU are willing to trust to assert name bindings for other
  42. > entities who are no longer in the name binding game.
  43.  
  44. I don't understand this at all, and I've just read the Rivest and Lampson
  45. paper from top to tail.  As far as I can see, all you get from their
  46. scheme's _naming_ technique (as distinct from their security architecture)
  47. that is different from a NAPTR style URN is the ability to refer to things
  48. as relative to yourself.  This doesn't appear to be too useful as if you
  49. distribute this name widely, people will either have to be given it in a
  50. global form or be told where you are in the global scheme of things and
  51. how your local namespace works.  You can't use somebody else's relative
  52. names without either having their principle name in your local namespace
  53. or just using their global name rooted at one of the special root names
  54. (Rivest and Lampson explicitly point this out in the paper, "The
  55. principal you call alice-smith may be different from the principal I call 
  56. alice-smith.".  So putting just "alice-smith" in a the bibliography of
  57. another document wouldn't be much use to anyone bar the creator). 
  58.  
  59. In fact, I'd say that they just describe a "LISPy" way of making a user
  60. interface allowing short cuts for commonly used parts of global
  61. namespaces. As they specifically say that their object names are just
  62. Octet strings, there's no reason why you couldn't use their security
  63. structure with the currently defined URN naming schemes.  Cool, a
  64. ready made security architecture that will work with URNs and that's been
  65. written by crypto big boys for free.  But I've probably misunderstood it
  66. all.
  67.  
  68. Tatty bye,
  69.  
  70. Jim'll
  71.  
  72. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  73. Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
  74. Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
  75. * I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *
  76.